Incident data collection for public protection agencies

ABSTRACT

An approach is provided in which a public protection system sends a data collection request to user devices located within a geographical proximity of an incident in progress that instructs the user devices to capture real-time data corresponding to the incident in progress. The public protection system receives the real-time data from the user devices and determines that a set of the real-time data includes evidence data corresponding to the incident in progress.

BACKGROUND

The present disclosure relates to a public protection system identifyinguser devices in proximity to an incident and collecting real-time datafrom the identified devices.

Today's public protection agencies constantly struggle with citizensreporting incorrect information and tips pertaining to an incident. Theincorrect information wastes valuable public protection agencies' timeand resources, and may also hinder the investigation of the incident. Inaddition, the public protection agencies may respond to an incident inprogress assuming the reported information is correct, only to discoverthat the incident is much different from originally reported.

In contrast, when a public protection agency receives timely andaccurate information, the public protection agency is much more preparedto resolve the incident. For example, if a law enforcement agencyreceives a correct license plate number of a thief's vehicle immediatelyfollowing a bank robbery, the law enforcement agency has a higherprobability of apprehending the thief.

BRIEF SUMMARY

According to one embodiment of the present disclosure, an approach isprovided in which a public protection system sends a data collectionrequest to user devices located within a geographical proximity of anincident in progress that instructs the user devices to capturereal-time data corresponding to the incident in progress. The publicprotection system receives the real-time data from the user devices anddetermines that a set of the real-time data includes evidence datacorresponding to the incident in progress.

The foregoing is a summary and thus contains, by necessity,simplifications, generalizations, and omissions of detail; consequently,those skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any way limiting. Otheraspects, inventive features, and advantages of the present disclosure,as defined solely by the claims, will become apparent in thenon-limiting detailed description set forth below.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The present disclosure may be better understood, and its numerousobjects, features, and advantages made apparent to those skilled in theart by referencing the accompanying drawings, wherein:

FIG. 1 is a diagram depicting an example of a public protection systemreceiving an incident alert and requesting real-time data from userdevices in proximity to the incident in progress;

FIG. 2 is a diagram depicting an example of a public protection systemsending tracking requests to devices in proximity to an incident inprogress;

FIG. 3 is a diagram depicting an example of a table that includesincident types, request types, and requested actions;

FIG. 4 is a diagram depicting an example of a user device displayingmessages to a user pertaining to an incident in progress;

FIG. 5 is a diagram depicting an example of a user device displayingmessages to a user pertaining to a fire in progress;

FIG. 6 is a diagram depicting an example of a user device displaying arequest to upload matching data;

FIG. 7 is a flowchart depicting an example of steps taken by a publicprotection system that requests real-time data from identified userdevices and analyzes the real-time data for evidence corresponding to anincident in progress;

FIG. 8 is a flowchart depicting an example of steps taken by a publicprotection system that sends a real-time data collection request to userdevices and receives real-time data from the user devices;

FIG. 9 is a flowchart depicting an example of steps taken by a userdevice that processes a request from a public protection system;

FIG. 10 is a flowchart depicting an example of steps taken by a userdevice to periodically receive unsolved incident data and determinewhether stored images correspond to the unsolved incident data;

FIG. 11 is a block diagram depicting an example of a data processingsystem in which the methods described herein can be implemented; and

FIG. 12 provides an extension of the information handling systemenvironment shown in FIG. 11 to illustrate that the methods describedherein can be performed on a wide variety of information handlingsystems which operate in a networked environment.

DETAILED DESCRIPTION

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the disclosure.As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present disclosure has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the disclosure in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the disclosure. Theembodiment was chosen and described in order to best explain theprinciples of the disclosure and the practical application, and toenable others of ordinary skill in the art to understand the disclosurefor various embodiments with various modifications as are suited to theparticular use contemplated.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions. The following detailed description willgenerally follow the summary of the disclosure, as set forth above,further explaining and expanding the definitions of the various aspectsand embodiments of the disclosure as necessary.

FIG. 1 is a diagram depicting an example of a public protection systemreceiving an incident alert and requesting real-time data from userdevices in proximity to the incident in progress. Public protectionsystem 100 supports agencies such as law enforcement, fire departments,emergency medical services (EMS), etc., and receives incident alert 140corresponding to incident 130 within geographical area 120. For example,public protection system 100 may be a 911-call center that supportsincidents that occur within a city.

Incident alert 140 includes information corresponding to an incident inprogress, such as a bank robbery, a building on fire, a person having aheart attack, etc. The information includes a geographical location ofincident 130, such a street address or GPS coordinates. Publicprotection system 100, in turn, determines incident proximity area 160around incident 130 and identifies user devices within incidentproximity area 160. In one embodiment, public protection system 100 usesphone tracking technology to identify devices located within incidentproximity area 160. The example in FIG. 1 shows that six citizens arelocated within geographical area 160, each of which having acorresponding a user device (e.g., smart phone).

Public protection system 100 sends data collection requests 150 to theproximate devices to collect real-time data pertinent to incident 130.For example, data collection requests 150 may include a request for thecitizens to video a fire in progress so the fire department is aware ofthe severity of the fire prior to arriving at the scene.

Public protection system 100 receives real-time data 170 from theproximate devices, which public protection system 100 analyzes forevidence data. For example, a burglary may be in progress and a devicemay provide an image of the burglar's vehicle. In turn, publicprotection system 100 may send additional requests to the user devicesbased upon analyzing real-time data 170, such as videotaping a vehicleas it leaves the scene of incident 130 (see FIG. 2 and correspondingtext for further details).

In one embodiment, public protection system 100 periodically providesunsolved incident data to registered devices to receive the unsolvedincident data. For example, a law enforcement agency may implement aprogram that encourages citizens to download license plate data ofstolen vehicles over the past six months in exchange for a reward whenthe user's device matches data stored on the user's device with theunsolved incident data. In this embodiment, the device alerts the userand the user may view the data prior to sending the data to the publicprotection system (see FIGS. 6, 10, and corresponding text for furtherdetails).

FIG. 2 is a diagram depicting an example of a public protection systemsending tracking requests to devices in proximity to an incident inprogress. Referring to FIG. 1, public protection system 100 receivedreal-time data 170 from devices in proximity to incident 130. In turn,public protection system 100 determined that a suspect is using vehicle200 to leave the scene of incident 130.

Public protection system 100 identifies area 210, which is in adirection that vehicle 200 is traveling, and identifies devices withinarea 210 that may provide real-time data, such as video of vehicle 200and whether vehicle 200 turns onto a different street. Public protectionsystem 100 sends tracking requests 220 to devices within area 210, whichmay include specific information such as “track blue van traveling Easton Main Street” (see FIG. 4 and corresponding text for further details).In turn, public protection system 100 receives real-time data 230 fromthe user devices in response to the user devices performing the actionsrequested by public protection system 100. In one embodiment, publicprotection system 100 offers a reward for the users of the devices toperform the requested actions.

FIG. 3 is a diagram depicting an example of a table that includesincident types, request types, and requested actions. Table 300 showsexamples of incident types managed by the public protection system, suchas incidents in progress and post-incidents. Incidents in progress maybe, for example, a bank robbery in progress, suspects in pursuit, abuilding on fire, a sinking boat, an altercation between people, orother events that are ongoing at the time that the public protectionsystem receives an incident alert.

Post-incidents correspond to events that have completed at the time thepublic protection system receives the incident alert, such as a houserobbery that occurred while the homeowners were on vacation.Post-incidents may also include unsolved incidents. For example, thepublic protection system may periodically download unsolved incidentdata to user devices, such as stolen vehicle information of unrecoveredvehicles. In this example, the user devices periodically comparecaptured data with the unsolved incident data to determine whether theuser device captured evidence data pertaining to an unsolved event (seeFIG. 10 and corresponding text for further details).

Line 310 corresponds to a real-time data collection request thatrequests a user device to collect real-time data in proximity to anincident in progress, such as still images, video, audio, etc. (see FIG.1 and corresponding text for further details). Line 320 corresponds to atracking request that requests a user to perform particular actions,such as videotape a vehicle leaving the scene of a crime (see FIG. 4 andcorresponding text for further details). Line 330 corresponds to acontact information requests that requests contact information of a userthat captured evidence data pertaining to an incident, such as theuser's name and phone number.

Regarding post-incident requests, line 340 corresponds to a dataanalysis request that requests the user device to analyze stored dataagainst incident data. For example, a vehicle may have been stolen sevendays ago and the public protection system may request a user device tosearch stored images taken within a particular time frame in aparticular geographical area for matching vehicles. In one embodiment,the user device periodically receives unsolved incident data andcompares captured media against the unsolved incident data (see FIG. 10and corresponding text for further details). Line 350 corresponds to acontact information requests that requests contact information of a userthat captured evidence data pertaining to an incident, such as theuser's name and phone number.

FIG. 4 is a diagram depicting an example of a user device displayingmessages to a user pertaining to an incident in progress. User device400 is located within an incident proximity area corresponding to anincident in progress (e.g., bank robbery). As such, the publicprotection system sends a real-time data collection request to userdevice 400. User device 400 displays message 410 to the user, whichrequests the user to capture real-time images (or video) of theintersection of 1^(st) Street and Main Street, which is the location ofthe incident in progress. The user selects accept 420 to participate inthe image collection, or selects reject 430 to reject the request.

When the user selects accept 420, the user device opens an image captureapplication and the user points the device towards 1^(st) Street andMain Street. The user device uploads the images to the public protectionsystem and, when the public protection system determines that the imagesinclude evidence data, the public protection system sends a trackingrequest to user device 400, which is displayed as message 440. Forexample, the user device may have uploaded an image of a blue van thatis suspect. The example in FIG. 4 shows that the public protectionsystem is requesting the user to capture video of a blue van travelingEast on Main Street (see FIG. 2 and corresponding text for furtherdetails). The user selects agree 450 to assist in the evidencecollection, or selects cancel 460 if the user does not wish to collectadditional data. In one embodiment, user device 400 may display a rewardmessage that indicates a monetary reward if the user assists in the datacollection.

FIG. 5 is a diagram depicting an example of a user device displayingmessages to a user pertaining to a fire in progress. User device 500 islocated within an incident proximity area of an apartment fire. As such,the public protection system sends a real-time data collection requestto user device 500, whereupon user device 500 displays message 510 tothe user requesting the user to capture real-time video of the fire onBroadway Street. The user selects accept 520 to partake in the videocollection, or selects reject 530 to reject the request.

When the user selects accept 520, the user device opens an image captureapplication and the user points the device towards the apartment fire.In one embodiment, the user device streams the video to the publicprotection system and allows the public protection system to sendtracking requests back to the user device accordingly. FIG. 5 shows thatthe public protection system highlighted arrow 540 to inform the user topan to the left so the public protection system user can view othersections of the apartment building. The public protection system, inturn, may relay information to fire personnel in transit as well asdetermine whether more fire trucks are required prior to the firepersonnel arriving at the scene.

FIG. 6 is a diagram depicting an example of a user device displaying arequest to upload matching data. In one embodiment, the publicprotection system determined that user device is within, or was within,an incident proximity area at the time of a previous incident. As such,the public protection system sends a request to user device 600,whereupon user device 600 analyzes stored images corresponding to a timeand location of the past incident.

In one embodiment, the request may be a periodic request to searchstored data (images, audio, video) for information that matches unsolvedincidents. In this embodiment, the public protection system may sendsuch requests to participating user devices regardless of whether theuser devices were in proximity to the unsolved incidents. For example, athief may steal a car in Texas but authorities believe that the thiefdrove the vehicle to Arizona. In this example, the public protectionsystem may send data analysis requests to participating user devicesthat are located in Arizona.

When the application detects a data match, the application displaysmessage 610 and provides the user with the option of sending the data(620), viewing or listening to the data (630) before sending the data,or canceling the data upload (640).

FIG. 7 is a flowchart depicting an example of steps taken by a publicprotection system that requests real-time data from identified userdevices and analyzes the real-time data for evidence corresponding to anincident in progress. Public protection system processing commences at700, whereupon the public protection system receives a report of anincident at step 710, such as a crime, a fire, etc. In one embodiment,the public protection system may be a centralized call center (e.g.,911-call center) or the public protection system may support a specificagency, such as a police department, fire department, or EMS facility.

The public protection system determines whether the incident is inprogress (decision 720). If the incident is in progress, decision 720branches to the “Yes” branch, whereupon the public protection systemsends requests to user devices within an incident proximity area of theincident and receives real-time data (pre-defined processing block 730,see FIG. 8 and corresponding text for further details). For example, abuilding may be on fire and the public protection system sends a requestto a nearby pedestrian to video the fire and stream the video to thepublic protection system. Processing ends at 735.

On the other hand, if the incident has completed, decision 720 branchesto the “No” branch. For example, a business owner may have discoveredthat a burglar vandalized his building the previous evening. At step740, the public protection system determines an incident proximity area,such as 500 feet from the incident, and identifies user devices locatedwithin the incident proximity area at an approximate time frame of theincident.

At step 750, the public protection system sends a data analysis requestto the identified user devices to analyze media stored on the userdevices that was captured at the approximate time frame. The publicprotection system receives media data from the user devices, at step760. The public protection system analyzes the data based upon theincident at step 770, and the public protection system determineswhether the data includes evidence data (decision 780). For example, athief may have stolen a car and an image may have captured the thiefbreaking into the car.

If the public protection system determines that the data includesevidence data, the public protection system, in one embodiment, sends anotification to the corresponding user device requesting the user of theuser device to provide contact information (step 790). In thisembodiment, the public protection system may provide the contactinformation to authorities that, in turn, may further question the userto obtain details of the incident. On the other hand, if the publicprotection system did not find evidence data, decision 780 branches tothe “No” branch, and processing ends at 795.

FIG. 8 is a flowchart depicting an example of steps taken by a publicprotection system that sends a real-time data collection request to userdevices and receives real-time data from the user devices. Publicprotection system processing commences at 800, whereupon the publicprotection system identifies an incident proximity area, such as 500feet from an incident in progress, and identifies user devices that arecurrently located within incident proximity area 160 (step 810).

At step 820, the public protection system sends a real-time datacollection request to the proximate user devices. In one embodiment, therequest may require the user to move locations, such as a request forthe user to video a house on fire around a corner. In anotherembodiment, the request may indicate a monetary amount available to theuser if the user agrees to cooperate with the real-time data collectionrequest.

The public protection system receives real-time data from the userdevices, which the public protection system analyzes at step 830. Thepublic protection system determines whether the data includes evidencedata, such as whether an image includes a black van parked outside thebank (decision 840). If the public protection system determines that thedata does not include evidence data, decision 840 branches to the “No”branch.

On the other hand, if the public protection system determines that thedata includes evidence data, a determination is made as to whether tosend a tracking request to the user device that provided the matchingreal-time data (decision 850). For example, a user device may bevideotaping a fire and the public protection system may request the userto pan in a particular direction (see FIG. 5 and corresponding text forfurther details). In another embodiment, a user device may have taken apicture of a black van leaving an incident in progress and the publicprotection system may request the user to video tape the van as itleaves the scene (see FIG. 4 and corresponding text for furtherdetails).

If the public protection system determines to send a tracking request,decision 850 branches to the “Yes” branch, whereupon the publicprotection system sends a tracking request to identified user devicesand receives subsequent real-time data accordingly (step 860). Thepublic protection system may periodically send additional trackingrequests to the identified user devices based upon the current situationof the incident in progress. On the other hand, if the public protectionsystem determines not to send a tracking request, decision 850 branchesto the “No” branch, bypassing step 860.

The public protection system determines whether to request user contactinformation (decision 870). As discussed above, by obtaining usercontact information, the public protection system may notify authoritiesthat, in turn, may further question the user of the device. If thepublic protection system determines not to request user contactinformation, decision 870 branches to the “No” branch and processingends at 890. On the other hand, if the public protection system wishesto obtain the user contact information, decision 870 branches to the“Yes” branch, whereupon the public protection system sends a contactinformation request to the user at 880. At step 885, the publicprotection system receives the user contact information after the userauthorizes the user device to send the contact information, associatesthe user contact information with the matched real-time data, andprocessing returns at 890.

FIG. 9 is a flowchart depicting an example of steps taken by a userdevice that processes a request from a public protection system. Deviceprocessing commences at 900, whereupon the device receives a requestfrom the public protection system at step 910. The request may includeincident data such as the location of the incident, the type ofincident, the time of the incident, etc. At step 915, the devicedisplays a message to the user and obtains authorization to process therequest. If the user does not authorize the request, device processingends (not shown).

A determination is made as to whether the request corresponds to anincident in progress or a post-incident (decision 920). If the requestpertains to a previous incident or unsolved incident, decision 920branches to the “Post-incident” branch, whereupon a device applicationcompares stored data against an incident database (step 920). Adetermination is made as to whether the device application matchedstored data against the incident database (decision 930). If the devicefound a match, decision 930 branches to the “Yes” branch, whereupon thedevice notifies the user and receives authorization to send the matchedmedia (step 940). Once the user provides authorization, the device sendsthe matched data to the public protection system (step 950). On theother hand, if a match was not found, decision 930 branches to the “No”branch and processing ends at 960.

Referring back to decision 920, if the request corresponds to anincident in progress, decision 920 branches to the “Incident InProgress” branch, whereupon a determination is made as to whether therequest is to provide streaming media, such as a live video stream or alive audio stream (decision 940). If the public protection systemrequests a live stream, decision 940 branches to the “Yes” branch,whereupon the device establishes a connection with the public protectionsystem and streams the media to the public protection system (step 945).In one embodiment, the device receives tracking requests, such as to pana building or videotape a van traveling down a road. In this embodiment,the device displays tracking requests to the user as required andresponds to the user's actions (step 950). Processing ends at 955.

Referring back to decision 940, if the public protection system does notrequest a live video feed, decision 940 branches to the “No” branch. Atstep 960, the device stores real-time data on the device. For example,the request may request a 10-minute period to take images every minuteof an incident area. At step 965, in one embodiment, the device analyzesthe images against the provided incident data and sends media determinedto include evidence data to the public protection system (step 970). Inanother embodiment, the device sends the real-time data to the publicprotection system and the public protection system analyzes thereal-time data for evidence data. Processing ends at 975.

FIG. 10 is a flowchart depicting an example of steps taken by a userdevice to periodically receive unsolved incident data and determinewhether stored images correspond to the unsolved incident data.

Processing commences at 1000, whereupon the public protection systemperiodically sends unsolved incident data to a participating user deviceat 1005. For example, the unsolved incident data may include licenseplate information of stolen vehicles over the past six months. In oneembodiment, the public protection system sends the unsolved incidentdata to participating user devices on a recurring basis, such as onceper week.

Device processing commences at 1060, whereupon the device receives theunsolved incident data and stores the unsolved incident data inincidents store 1068 (step 1065). At step 1070, the device compares theunsolved incident data with stored images in image store 1072. In oneembodiment, the device identifies images to search based upon a timestamp. For example, if a vehicle was stolen on Mar. 1, 2014, the devicesearches images taken subsequent to Mar. 1, 2014. Continuing with thisexample, if the device has images taken on Mar. 1, 2014 that have GPScoordinates in proximity to the location of where the vehicle wasstolen, the device may perform an added layer of analysis on the imageor mark the image to send to the public protection system for furtheranalysis.

Processing determines whether the device identified stored data thatmatch the unsolved incident data (decision 1075). If the device did notidentify a match, decision 1075 branches to the “No” branch, whereuponprocessing ends at 1095. On the other hand, if the device identified amatch, decision 1075 branches to the “Yes” branch, whereupon the devicenotifies the user and receives user authorization at step 1080 to sendthe data (see FIG. 6 and corresponding text for further details). Atstep 1085, the device sends the images to the public protection system.

Returning to the public protection system processing, the publicprotection system receives the images at step 1010, and the publicprotection system determines whether to request contact information fromthe user for further questioning (decision 1020). For example, an imagemay include substantial evidence data and a law enforcementrepresentative may wish to ask the user further questions. If the publicprotection system would like contact information, decision 1020 branchesto the “Yes” branch, whereupon the public protection system sends arequest for contact information at step 1030.

The device receives the request at step 1090, obtains authorization fromthe user to send the user's contact information, and the device sendsthe user's contact information to the public protection systemaccordingly, such as the user's name and phone number. Device processingends at 1095. The public protection system receives the user's contactinformation at step 1040, and public protection system processing endsat 1050.

FIG. 11 illustrates information handling system 1100, which is asimplified example of a computer system capable of performing thecomputing operations described herein. Information handling system 1100includes one or more processors 1110 coupled to processor interface bus1112. Processor interface bus 1112 connects processors 1110 toNorthbridge 1115, which is also known as the Memory Controller Hub(MCH). Northbridge 1115 connects to system memory 1120 and provides ameans for processor(s) 1110 to access the system memory. Graphicscontroller 1125 also connects to Northbridge 1115. In one embodiment,PCI Express bus 1118 connects Northbridge 1115 to graphics controller1125. Graphics controller 1125 connects to display device 1130, such asa computer monitor.

Northbridge 1115 and Southbridge 1135 connect to each other using bus1119. In one embodiment, the bus is a Direct Media Interface (DMI) busthat transfers data at high speeds in each direction between Northbridge1115 and Southbridge 1135. In another embodiment, a Peripheral ComponentInterconnect (PCI) bus connects the Northbridge and the Southbridge.Southbridge 1135, also known as the I/O Controller Hub (ICH) is a chipthat generally implements capabilities that operate at slower speedsthan the capabilities provided by the Northbridge. Southbridge 1135typically provides various busses used to connect various components.These busses include, for example, PCI and PCI Express busses, an ISAbus, a System Management Bus (SMBus or SMB), and/or a Low Pin Count(LPC) bus. The LPC bus often connects low-bandwidth devices, such asboot ROM 1196 and “legacy” I/O devices (using a “super I/O” chip). The“legacy” I/O devices (1198) can include, for example, serial andparallel ports, keyboard, mouse, and/or a floppy disk controller. TheLPC bus also connects Southbridge 1135 to Trusted Platform Module (TPM)1195. Other components often included in Southbridge 1135 include aDirect Memory Access (DMA) controller, a Programmable InterruptController (PIC), and a storage device controller, which connectsSouthbridge 1135 to nonvolatile storage device 1185, such as a hard diskdrive, using bus 1184.

ExpressCard 1155 is a slot that connects hot-pluggable devices to theinformation handling system. ExpressCard 1155 supports both PCI Expressand USB connectivity as it connects to Southbridge 1135 using both theUniversal Serial Bus (USB) the PCI Express bus. Southbridge 1135includes USB Controller 1140 that provides USB connectivity to devicesthat connect to the USB. These devices include webcam (camera) 1150,infrared (IR) receiver 1148, keyboard and trackpad 1144, and Bluetoothdevice 1146, which provides for wireless personal area networks (PANs).USB Controller 1140 also provides USB connectivity to othermiscellaneous USB connected devices 1142, such as a mouse, removablenonvolatile storage device 1145, modems, network cards, ISDN connectors,fax, printers, USB hubs, and many other types of USB connected devices.While removable nonvolatile storage device 1145 is shown as aUSB-connected device, removable nonvolatile storage device 1145 could beconnected using a different interface, such as a Firewire interface,etcetera.

Wireless Local Area Network (LAN) device 1175 connects to Southbridge1135 via the PCI or PCI Express bus 1172. LAN device 1175 typicallyimplements one of the IEEE 802.11 standards of over-the-air modulationtechniques that all use the same protocol to wireless communicatebetween information handling system 1100 and another computer system ordevice. Optical storage device 1190 connects to Southbridge 1135 usingSerial ATA (SATA) bus 1188. Serial ATA adapters and devices communicateover a high-speed serial link. The Serial ATA bus also connectsSouthbridge 1135 to other forms of storage devices, such as hard diskdrives. Audio circuitry 1160, such as a sound card, connects toSouthbridge 1135 via bus 1158. Audio circuitry 1160 also providesfunctionality such as audio line-in and optical digital audio in port1162, optical digital output and headphone jack 1164, internal speakers1166, and internal microphone 1168. Ethernet controller 1170 connects toSouthbridge 1135 using a bus, such as the PCI or PCI Express bus.Ethernet controller 1170 connects information handling system 1100 to acomputer network, such as a Local Area Network (LAN), the Internet, andother public and private computer networks.

While FIG. 11 shows one information handling system, an informationhandling system may take many forms. For example, an informationhandling system may take the form of a desktop, server, portable,laptop, notebook, or other form factor computer or data processingsystem. In addition, an information handling system may take other formfactors such as a personal digital assistant (PDA), a gaming device, ATMmachine, a portable telephone device, a communication device or otherdevices that include a processor and memory.

FIG. 12 provides an extension of the information handling systemenvironment shown in FIG. 11 to illustrate that the methods describedherein can be performed on a wide variety of information handlingsystems that operate in a networked environment. Types of informationhandling systems range from small handheld devices, such as handheldcomputer/mobile telephone 1210 to large mainframe systems, such asmainframe computer 1270. Examples of handheld computer 1210 includepersonal digital assistants (PDAs), personal entertainment devices, suchas MP3 players, portable televisions, and compact disc players. Otherexamples of information handling systems include pen, or tablet,computer 1220, laptop, or notebook, computer 1230, workstation 1240,personal computer system 1250, and server 1260. Other types ofinformation handling systems that are not individually shown in FIG. 12are represented by information handling system 1280. As shown, thevarious information handling systems can be networked together usingcomputer network 1200. Types of computer network that can be used tointerconnect the various information handling systems include Local AreaNetworks (LANs), Wireless Local Area Networks (WLANs), the Internet, thePublic Switched Telephone Network (PSTN), other wireless networks, andany other network topology that can be used to interconnect theinformation handling systems. Many of the information handling systemsinclude nonvolatile data stores, such as hard drives and/or nonvolatilememory. Some of the information handling systems shown in FIG. 12depicts separate nonvolatile data stores (server 1260 utilizesnonvolatile data store 1265, mainframe computer 1270 utilizesnonvolatile data store 1275, and information handling system 1280utilizes nonvolatile data store 1285). The nonvolatile data store can bea component that is external to the various information handling systemsor can be internal to one of the information handling systems. Inaddition, removable nonvolatile storage device 1145 can be shared amongtwo or more information handling systems using various techniques, suchas connecting the removable nonvolatile storage device 1145 to a USBport or other connector of the information handling systems.

While particular embodiments of the present disclosure have been shownand described, it will be obvious to those skilled in the art that,based upon the teachings herein, that changes and modifications may bemade without departing from this disclosure and its broader aspects.Therefore, the appended claims are to encompass within their scope allsuch changes and modifications as are within the true spirit and scopeof this disclosure. Furthermore, it is to be understood that thedisclosure is solely defined by the appended claims. It will beunderstood by those with skill in the art that if a specific number ofan introduced claim element is intended, such intent will be explicitlyrecited in the claim, and in the absence of such recitation no suchlimitation is present. For non-limiting example, as an aid tounderstanding, the following appended claims contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimelements. However, the use of such phrases should not be construed toimply that the introduction of a claim element by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim element to disclosures containing only one suchelement, even when the same claim includes the introductory phrases “oneor more” or “at least one” and indefinite articles such as “a” or “an”;the same holds true for the use in the claims of definite articles.

The invention claimed is:
 1. An information handling system comprising:one or more processors; a memory coupled to at least one of theprocessors; a set of computer program instructions stored in the memoryand executed by at least one of the processors in order to performactions of: sending a data collection request from the informationhandling system to one or more user devices located within ageographical proximity of an incident in progress, wherein the datacollection request is sent prior to receiving information pertaining tothe incident in progress from at least one of the one or more userdevices, and wherein each of the one or more user devices is instructedto capture real-time data corresponding to the incident in progress;receiving, at the information handling system, the real-time datacaptured by the one or more user devices that includes evidence datacorresponding to the incident in progress; sending a tracking request,based on analyzing the evidence data, from the information handlingsystem to one or more different user devices that are not part of theone or more user devices, wherein the tracking request corresponds to adifferent location than a location of the incident in progress;receiving, at the information handling system, subsequent real-time datafrom at least one of the one or more different user devices; andproviding, by the information handling system, the subsequent real-timedata to one or more public service users.
 2. The information handlingsystem of claim 1 wherein the real-time data is selected from the groupconsisting of still image data, video data, and audio data.
 3. Theinformation handling system of claim 1 wherein the processors performadditional actions comprising: identifying a first one of the one moredevices that provided the evidence data; sending a request to the firstdevice to provide user contact information of a user of the firstdevice; receiving the user contact information from the first device;and linking the user contact information to the evidence data.
 4. Theinformation handling system of claim 1 wherein the tracking request is arequest to provide a live video stream.
 5. The information handlingsystem of claim 3 wherein the processors perform additional actionscomprising: sending a reward notification to the first device inresponse to the first device providing the evidence data.
 6. Theinformation handling system of claim 1 wherein the processors performadditional actions comprising: providing unsolved incident data to oneor more participating user devices, wherein the unsolved incident dataincludes information corresponding to one or more unsolved incidents;and receiving, from a first one of the one or more participating userdevices, post-incident data matched to the unsolved incident data,wherein the post-incident data was captured subsequent to acorresponding one of the one or more unsolved incidents.
 7. The computerprogram product of claim 6 wherein the information handling systemperforms further actions comprising: providing unsolved incident data toone or more participating user devices, wherein the unsolved incidentdata includes information corresponding to one or more unsolvedincidents; and receiving, from a first one of the one or moreparticipating user devices, post-incident data matched to the unsolvedincident data, wherein the post-incident data was captured subsequent toa corresponding one of the one or more unsolved incidents.
 8. A computerprogram product stored in a computer readable storage device, comprisingcomputer program code that, when executed by an information handlingsystem, causes the information handling system to perform actionscomprising: sending a data collection request from the informationhandling system to one or more user devices located within ageographical proximity of an incident in progress, wherein the datacollection request is sent prior to receiving information pertaining tothe incident in progress from at least one of the one or more userdevices, and wherein each of the one or more user devices is instructedto capture real-time data corresponding to the incident in progress;receiving, at the information handling system, the real-time datacaptured by the one or more user devices that includes evidence datacorresponding to the incident in progress; sending a tracking request,based on analyzing the evidence data, from the information handlingsystem to one or more different user devices that are not part of theone or more user devices, wherein the tracking request corresponds to adifferent location than a location of the incident in progress;receiving, at the information handling system, subsequent real-time datafrom at least one of the one or more different user devices; andproviding, by the information handling system, the subsequent real-timedata to one or more public service users.
 9. The computer programproduct of claim 8 wherein the real-time data is selected from the groupconsisting of still image data, video data, and audio data.
 10. Thecomputer program product of claim 8 wherein the information handlingsystem performs further actions comprising: identifying a first one ofthe one more devices that provided the evidence data; sending a requestto the first device to provide user contact information of a user of thefirst device; receiving the user contact information from the firstdevice; and linking the user contact information to the evidence data.